IBIS Macromodel Task Group

Meeting date: 03 May 2016

Members (asterisk for those attending):
ANSYS:                      * Dan Dvorscak
                            * Curtis Clark
Broadcom (Avago):             Xingdong Dai
                              Bob Miller
Cadence Design Systems:     * Ambrish Varma
                              Brad Brim
                              Kumar Keshavan
                              Ken Willis
Cisco:                        Seungyong (Brian) Baek
eASIC:                        David Banas
                              Marc Kowalski
Ericsson:                     Anders Ekholm
GlobalFoundries:              Steve Parker
Intel:                        Michael Mirmak
Keysight Technologies:        Fangyi Rao
                            * Radek Biernacki
                            * Ming Yan
Maxim Integrated Products:    Hassan Rafat
Mentor Graphics:            * John Angulo
                            * Arpad Muranyi
Micron Technology:          * Randy Wolff
                              Justin Butterfield
QLogic Corp.:                 James Zhou
                              Andy Joy
SiSoft:                     * Walter Katz
                              Todd Westerhoff
                            * Mike LaBonte
Synopsys:                     Rita Horner
Teraspeed Consulting Group:   Scott McMorrow
Teraspeed Labs:             * Bob Ross
TI:                           Alfred Chong


The meeting was led by Arpad Muranyi.

--------------------------------------------------------------------------------
Opens:

- Arpad asked if we should consider cancelling next week's meeting because of
  the European IBIS Summit at SPI.  Walter and Randy said they would be
  traveling to the Summit and unable to attend.  Because they were the only
  two unable to attend, the group decided not to cancel next week's meeting.

-------------
Review of ARs:

- Ambrish to check for a collaborator's feedback on his nearly ready new
  version of the Backchannel proposal.
  - In progress.  Ambrish confirmed that he had sent the most recent draft
    to Arpad prior to the April 19th meeting.  Walter and Bob also asked to
    receive a pre-release copy.  Ambrish agreed to send it to them.

--------------------------
Call for patent disclosure:

- None.

-------------------------
Review of Meeting Minutes:

Minutes from April 19:
- Arpad: Does anyone have any comments or corrections? [none]
- Dan: Motion to approve the minutes.
- Randy: Second.
- Arpad: Anyone opposed? [none]

Minutes from April 26:
- Arpad: Does anyone have any comments or corrections? [none]
- Dan: Motion to approve the minutes.
- Mike: Second.
- Arpad: Anyone opposed? [none]

-------------
New Discussion:

[Pin Reference] BIRD Draft:
- Arpad: Do we have questions, comments, discussion on last week's presentation?
- Radek: It is what I have been advocating for some time.
  - It is definitely a step in the right direction.
  - Details concerning whether signal_name, bus_label, or another Pin can serve
    as the reference are to be worked out.  But those are details and this
    feature is important.
- Bob: I agree that bus_label vs. signal_name needs to be resolved.
  - Only I/O Pins should appear, not POWER, GND, NC, or even terminator Models.
  - Basing things on one reference may not reflect the specifications or
    internal circuitry of some buffers.  That's a concern, and we may need
    to add a statement to that effect.
- Mike: [sharing a new draft of the [Pin Reference] BIRD proposal]
- Discussion: Mike noted that he had made some editorial changes.  Mike asked
  whether VT, IV, ISSO all belonged in the same category of voltages that are
  referenced to some additional reference node in the circuit.  After some
  discussion, the group agreed that IV and ISSO tables were fully specified
  with respect to the I/O pad and power supply terminals themselves, and
  therefore could be removed from this [Pin Reference] proposal.
  
  Mike noted that Bob preferred that bus_label serve as the reference rather
  than a signal_name.  Radek stated that either one would probably be fine.
  Mike said that from the EDA tool's perspective it needs to identify some
  terminal or node to use as the reference, and the question was which one
  allows the tool to identify the node that is closest to what was actually
  used at the time of the measurement.  Radek said it simply depended on
  whether [Pin Mapping] were present, and that if [Pin Mapping] were not
  present then signal_name would be fine.  Radek and Walter both supported this
  sense of signal_name as an implicit bus_label.  Bob, however, expressed
  concern about ambiguities if [Pin Mapping] were not present.  For the sake
  of simplicity in the proposal, therefore, Walter agreed to use bus_label
  instead of signal_name, which makes [Pin Mapping] mandatory instead of
  optional [this change is reflected in the posted document].
  
  Bob noted concern over multiple instances of the forward referencing of
  keywords that were not defined until later.  Mike suggested that we should
  make simple ordering decisions to mitigate those issues where possible, but
  that we should not let forward referencing derail a good proposal.  He also
  noted that IBIS had always set itself up for forward referencing issues by
  defining the [Component] keyword first.  Arpad noted that in general it was
  always advantageous to keep most of the information related to a given topic
  or keyword in one place.  Even people familiar with the spec would have to
  look things up on occasion, and if a keyword's section didn't describe
  everything then it was easy to miss something.  Bob agreed and said that he
  felt this keyword should be in the [Component] section (section 5) and should
  include language indicating that certain forward referenced terms are defined
  later (section 6). Radek suggested that syntax, etc., could be defined in the
  keyword section itself, but that discussion of effects relative to other
  keywords could appear with those keywords.
  
- Bob: [sharing an ad hoc presentation on [Pin Reference] Cases]
- Discussion: Bob reviewed his presentation including slides illustrating
  threshold specifications for various technologies.  Using CMOS as one
  example it shows proportional thresholds based on Vcc, e.g., Vil = 0.3*VCC.
  The presentation describes the term "dominant" reference, and suggests that
  VCC might be the dominant reference in the CMOS case, but that the thresholds
  are still a function of the "ground" and VCC.  Other technologies and their
  relationships between thresholds and two different rails were also listed.
  Walter stated, however, that thresholds should always be expected to vary
  based on the difference between the two power rails, and that these examples
  were not unique in relying on two voltage rails.  He noted that the existing
  [Receiver Thresholds] keyword provides an overly simplistic version of this
  threshold mapping by assuming the "ground" rail is fixed at 0.

- Arpad: I think this BIRD will be the topic for next week, so I encourage
         everyone to review this new draft carefully.
- Arpad: Thank you all for joining.

-------------
Next meeting: 10 May 2016 12:00pm PT
-------------

IBIS Interconnect SPICE Wish List:

1) Simulator directives
